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Description 

SYSTEM AND METHOD FOR REMOTE 
COLLECTION OF DATA 

Cross Reference to Related Applications 

[0001] This application claims priority to, and the benefit of, U.S. 

Provisional Application Serial No. 60/491,500 filed July 

30, 2003 and entitled "Data Collection System and 

Method", which is hereby incorporated by reference. 
Field of Invention 

[0002] The present invention relates generally to the manage- 
ment of electronic forms within remote computing devices 
and providing reliable synchronization of both data and 
executable code with backend financial systems, and 
more particularly, to a system and method which enables 
in-field financial advisors to access and utilize electronic 
forms relating to financial products and financial advise 
applications utilizing a tablet PC or other portable com- 
puting device. 
Background of Invention 



[0003] Corporations which provide financial advice to clients and 
customers, either directly or through financial profession- 
als, typically place a premium upon the delivery of consis- 
tent and complementary advice across the various chan- 
nels that may be available for delivering such advice. Fi- 
nancial planners and planning organizations generally 
provide their customers with financial advice such as data, 
strategies, and recommendations. In addition to utilizing 
charts, graphs, and other visual aids for presenting this 
financial advice to clients, financial planners and planning 
organizations often use specialized calculators, simula- 
tors, formatters, and the like to augment the depth and 
quality of the proffered financial advice. Moreover, due to 
various Security and Exchange Commission, insurance, fi- 
nancial, legal, and other complex disclosure requirements, 
the financial data generated during the financial planning 
process should be appropriately archived, and the finan- 
cial advice information delivered to the client should in- 
clude the proper disclosures, disclaimers, and the like. 

[0004] | n addition to the disclosures and disclaimers that cus- 
tomers usually review and sign, financial advisors often 
enroll new or existing customers into new services or as- 
sist new or existing customers through application pro- 



cesses for financial products and services. Such enrolment 
and application processes often require the customer to 
complete one or more forms. Traditionally, financial advi- 
sors are equipped with a number of different paper forms 
geared to various types of financial products and services. 
A financial advisor may complete forms on behalf of the 
customer, however, the customer typically must sign 
forms to indicate acceptance of the information in the 
forms. This is most often a time consuming and tedious 
task. Further, when a financial advisor returns from the 
field, all forms and disclosures relating to a sale or change 
in financial services are turned over to data entry person- 
nel. It is then the job of the data entry personnel to enter 
information from the forms into the appropriate database 
systems. This not only creates redundancy, but it creates 
a new layer for data entry errors to occur. 
[0005] it therefore is desirable to create a system for managing 
applications, data and electronic forms in remote environ- 
ments where a means for connecting to a financial ser- 
vices company computing center is either not conve- 
niently present or not accessible. Additionally, it is desir- 
able to provide a system for presenting forms electroni- 
cally and collecting form data through a pen based PC, 



such as a tablet PC. 
Summary of Invention 

[0006] The present invention overcomes the limitations and 
problems of the prior art by providing a system and 
method for managing electronic forms and financial ad- 
vice applications in remote environments. The system 
provides a secure, reliable and convenient means to sup- 
port in-field financial advisors by providing the advisor 
with the most current forms, data and applications and 
providing a means to compile and present the appropriate 
forms to be completed electronically by advisors and/or 
customers. 

[0007] jhe invention includes a method for managing electronic 
forms which includes: transmitting at least one host form 
having form fields from a host to a remote device having a 
remote database; entering form data into the form fields 
to create a remote form; communicating with the host to 
transmit the remote form to the host; mapping the form 
fields to database record fields within a database of the 
host; and, synchronizing the host database with the re- 
mote database. 
Brief Description of Drawings 



[0008] a more complete understanding of the present invention 
may be derived by referring to the detailed description 
and claims when considered in connection with the Fig- 
ures, wherein like reference numbers refer to similar ele- 
ments throughout the Figures, and: 

[0009] Figure 1 is a diagram illustrating an exemplary grouping 
of system components and functionality into tiers; 

[0010] Figure 2 is a block diagram illustrating major system 

components for an exemplary system for supporting vari- 
ous client systems; 

[0011] Figure 3 is a flow chart illustrating an exemplary method 
for compiling and completing electronic forms in a remote 
environment; 

[0012] Figure 4 is a flow chart illustrating an exemplary method 
for synchronizing executable code and data between a re- 
mote user computing device and the main system compo- 
nents of the financial institution. 
Detailed Description 

[0013] The detailed description of exemplary embodiments of 

the invention herein makes reference to the accompanying 
drawings, which show the exemplary embodiment by way 
of illustration and its best mode. While these exemplary 
embodiments are described in sufficient detail to enable 



those skilled in the art to practice the invention, it should 
be understood that other embodiments may be realized 
and that logical and mechanical changes may be made 
without departing from the spirit and scope of the inven- 
tion. Thus, the detailed description herein is presented for 
purposes of illustration only and not of limitation. 

[0014] | n general, the invention includes a system and method 

for managing electronic forms and/or financial advise ap- 
plications within various computing environments. Refer- 
ring to Figure 1, the system may best be described in 
tiers. The client tier 115 may comprise one or more client 
types differentiated from each other by the means each 
employ to communicate with and communicate with the 
various systems of the present invention. 

[0015] a client, as used herein, unless specifically stated other- 
wise, may comprise any hardware and/or software suit- 
ably configured to interact with the system, such as a per- 
sonal computer, personal digital assistant, laptop com- 
puter, tablet computer, network computer, workstation, 
minicomputer, mainframe, and/or the like. A client may 
be equipped with a device to facilitate communications 
such as a modem or Ethernet card. A client may commu- 
nicate with the various components of the present inven- 



tion through any system, device or method discussed 
herein or known in the art. 
[0016] a local area network (LAN) or wide area network (WAN) 
client 120 may include local workstations and personal 
computers that interact with the system components 
through dedicated network connections. A LAN connects 
computers in a relatively small area, such as the same 
floor or building, or a group of buildings like a campus. 
An example of a LAN connection would be an Ethernet 
connection between a client computing unit and various 
servers, hosts, and mainframe systems. A WAN is a physi- 
cal or logical network that provides capabilities for a 
number of independent devices to communicate with each 
other over a common transmission-interconnected topol- 
ogy in geographic areas larger than those served by local 
area networks. 

[0017] An intranet client 125 may interact with the various sys- 
tem components of the present invention through a stan- 
dard dial-up connection to a secured Internet server or 
through a high-speed connection such as DSL or cable. 
An intranet client 125 may not interact with a services tier 
110 directly, but through an intranet server (not shown) 
which may serve as an liaison between an intranet client 



125 and an authentication server 150, for example. 
[0018] a remote client 130 may have only an occasional connec- 
tion to the system components of the present invention. A 
remote client 130 may retain within memory a full or par- 
tial replication of computer programs and data that are 
stored within an applications tier 105 and/or data tier 100 
of the present invention. A remote client 130 may be pro- 
vided the same utility as a LAN/WAN client 120 or an in- 
tranet client 125 although all of the applications and data 
may reside in the device's memory. A remote client 130 
may occasionally communicate with the various systems 
of the present invention through a LAN/WAN or Intranet 
connection in order to synchronize it's applications and/or 
data with that of an applications tier 105 and/or data tier 
100. 

[0019] a services tier 110 may comprise hardware and/or soft- 
ware suitably configured to manage transactions between 
the client tier 115 and applications tier 105. A services 
tier 110 may receive requests from a client tier 115 and 
process, format, and route the request to the appropriate 
application in the applications tier 105. Further, services 
tier 110 may facilitate the transfer of data between a 
client tier 115 and a data tier 100 independent of the ap- 



plications tier 105. 
[0020] The data migration mechanism utilized in the exemplary 
system may include a conversion server, such as XML ap- 
plication server 145, which enables components within 
the services tier 110 to send suitably standardized data to 
the data tier 100, and a translator, such as XML translator 
155, which enables the data tier 100 to send suitably 
standardized data to the applications server 145 and 
among other components within the services tier 110. In 
an exemplary embodiment, the XML translator 155 is the 
subsystem responsible for retrieving or reading objects 
from the services tier 110 and translating those objects 
into a suitable standardized data format, such as XML for 
example. 

[0021] The process of translating objects into XML may be re- 
ferred to as "externalization" and, conversely, reading in 
XML and translating into suitable objects may be referred 
to as "internalization". In an exemplary embodiment, an 
XML translator 155 includes a hierarchy of translators 
which suitably correspond to the many types of objects 
that that may require translation. An XML translator 155 
may implement the translation of any suitable program- 
ming or scripting language, such as Java, Smalltalk, and/ 



or the like. 

[0022] Synchronization server 140 facilitates the synchronization 
of data between a remote client 130 with a suitable con- 
nection to a synchronization server 140. Synchronization 
server initiates a synchronization utility 160 which con- 
tains logic enabling it to compare data stored within a re- 
mote client's 130 local database with data stored within 
any number of databases in the data tier 100. A synchro- 
nization utility 160 may examine records within various 
databases to determine if new records have been added, 
deleted, or modified and flag databases that should be 
updated. Further, a synchronization utility 160 may query 
a database in the data tier 100 in order to determine if a 
database structure has been changed. If this is the case, 
synchronization utility 160 may transmit a new replication 
of the database to a remote client 130. A synchronization 
utility 160 ensures that the replicated databases residing 
on the remote client 130 and the one or more databases 
within the data tier 100 contain consistent and accurate 
data. 

[0023] a synchronization server 140 may also employ a synchro- 
nization utility 160 to ensure that computer programs and 
executable code residing on a remote client 130 are con- 



sistent with those residing in the applications tier 105. For 
example, a financial adviser equipped with a remote client 
130 may have financial application loaded into it's local 
memory in order to utilize the financial application while 
in the field. If a developer modifies financial application 
170 within the applications tier 105, the remote client 130 
will be operating an outdated version of the financial ap- 
plication. However, if the remote client 130 connects to 
the synchronization server 140, the synchronization utility 
160 may compare the financial application of the remote 
client 130 to the financial application 170 in the applica- 
tions tier 105. This comparison may be executed by any 
means known in the art such as, for example, calculating 
a hash value for each application or by a more simple 
method of comparing application version data and/or 
modification dates. If a financial application on a remote 
client 130 is found to be inconsistent with it's counterpart 
within an applications tier 105, then a synchronization 
server 140 may load a new application onto the remote 
client 130. 

[0024] An applications server 145 may process requests from the 
client tier 115 in order to provide a user with access to the 
appropriate applications. Applications server 145 may 



communicate with any suitable number client systems and 
any suitable number of applications. Further, an applica- 
tions server may import any suitable number of third- 
party services, tools, or applications for use by compo- 
nents within the client tier 115, services tier 110, applica- 
tions tier 105 and data tier 110. The applications server 
145 suitably provides a framework for handling client/ 
server communications by listening for requests from 
multiple clients in the client tier 115 and spawning 
threads to handle each client communication. The appli- 
cations server 145 may also provide mechanisms for 
maintaining contextual information across connections, 
thereby providing a virtual communications across many 
requests. 

[0025] Authentication server 150, such as the American Express® 
DSS Service, may be configured for authenticating or au- 
thorizing use of the various components in the applica- 
tions tier 105 by a system in the client tier 115. Authenti- 
cation server 150 may include a database 175 for storing 
appropriate data used in authenticating a user in the 
client tier 115. Security data 175 may be any suitable 
database, including an object-oriented database, a rela- 
tional database, and/or the like. Any suitable authenticat- 



ing data may be stored in security database 180 and may 
include data such as a client identification number, a 
password, a pass phrase, any combination of these, and/ 
or the like. 

[0026] a forms utility 165 may comprise any software and/or 

hardware suitably configured to construct, compile, serve, 
validate, and parse form data. Forms utility 165 may com- 
prise one or more third party tools, custom tools, or a 
combination thereof. For example, the forms utility may 
employ Microsoft Office InfoPath™ to enable developers to 
author customized forms and define business logic and 
rules to imbed in the forms. Form fields may be mapped 
to any number of different databases in the data tier 100 
and to any number of database record fields. 

[0027] The data tier 100 may comprise any number of databases, 
database management systems, backend servers, main- 
frames and any other components of a financial manage- 
ment system. 

[0028] As will be appreciated by one of ordinary skill in the art, 
the present invention may be embodied as a customiza- 
tion of an existing system, an add-on product, upgraded 
software, a stand alone system (e.g., kiosk), a distributed 
system, a method, a data processing system, a device for 



data processing, and/or a computer program product. Ac- 
cordingly, the present invention may take the form of an 
entirely software embodiment, an entirely hardware em- 
bodiment, or an embodiment combining aspects of both 
software and hardware. Furthermore, the present inven- 
tion may take the form of a computer program product on 
a computer-readable storage medium having computer- 
readable program code means embodied in the storage 
medium. Any suitable computer-readable storage medium 
may be utilized, including hard disks, CD-ROM, optical 
storage devices, magnetic storage devices, and/or the 
like. 

[0029] An advisor, as used herein, may include any end-user who 
interacts with the present invention and participates in 
and/or directs customers in the completion of forms re- 
quired in the sale of financial products. Such advisor may 
be an individual, an entity, a business, a financial profes- 
sional, software, hardware, and/or the like. An advisor 
may also interact with financial advice applications which 
may include, for example, financial simulators, equity 
evaluators, asset allocation, financial calculators, and the 
like. 

[0030] a customer, as used herein, may be an individual, a family 



unit, a business, an entity, an organization, a government 
entity, software, hardware, or anyone who interacts with 
an advisor to shop and/or configure financial products. A 
customer may include, for example an individual shop- 
ping for investment accounts, retirement accounts, insur- 
ance products and the like. Further, a customer may com- 
prise a business who is in need of a business line of 
credit, loans, wholesale purchasing programs, accounting 
services, etc. 

[0031] Figure 2 is a block diagram illustrating exemplary rela- 
tionships between the major system components for an 
exemplary system for supporting various client systems. A 
LAN/WAN client 225 may communicate with an authenti- 
cation server 245 in order to enter credentials identifying 
the user as an authorized user of the system. The LAN/ 
WAN client 215 connection should be assumed to be over 
a secure private network, therefore connecting through an 
intranet portal may not be required. An intranet client 220 
and remote client 225 may communicate with an intranet 
server 235 through a secure or unsecured network con- 
nection such as a dial-up, cable, or DSL connection. A re- 
mote client 225 may include one or more local databases 
290 that comprise data replicated from corresponding 



backend 200 databases. A connection to an intranet 
server 235 may pass through a firewall in order to protect 
components within the intranet services (IS) 210. 
[0032] Firewall 230 may include any hardware and/or software 
suitably configured to protect intranet server 235 from 
users from other networks and provide limited or re- 
stricted access to intranet clients 220 and remote clients 
225. Firewall 230 may comprise varying configurations in- 
cluding Stateful Inspection, Proxy based and Packet Filter- 
ing among others. Firewall 230 may be integrated within 
intranet server 235, any other system components or may 
reside as a standalone component of the present inven- 
tion. 

[0033] intranet server 235 may include any hardware and/or 

software suitably configured to serve webpages and to re- 
ceive and process requests from clients. An intranet server 
may be advantageous to the present invention by restrict- 
ing access to unauthorized users through requiring users 
to provide authentication credentials. This may include 
any combination of a user ID, password, access code or 
any other means known in the art for authenticating 
users. Authentication credentials may be maintained 
within a user database 240 which may include any hard- 



ware and/or software suitably configured to facilitate 
storing user credentials. Intranet server 235 may send re- 
quests to the user database 240 in order to validate user 
supplied credentials. User database 240 may include any 
hardware and/or software suitably configured to facilitate 
storing user data including user authentication creden- 
tials. 

[0034] clients connecting through an IS 210 may access the sys- 
tems of the financial services (FS) 205 by passing through 
an authentication server 245. An authentication server 
245 may be desirable as not all users will access the com- 
ponents with the FS 205 through an IS 210. In one em- 
bodiment, authentication server 245 credentials may be 
stored within the user database 240 to eliminate the need 
for a connecting user to enter two sets of authentication 
data. An intranet server 235 may pass authentication 
server 245 a user's credentials transparently. Authoriza- 
tion server may send supplied credentials in a request to 
an authentication database 250. Authorization database 
250 may include any hardware and/or software suitably 
configured to facilitate storing user data including user 
authentication credentials. 

[0035] An applications server 260 may include any hardware 



and/or software suitably configured to facilitate transac- 
tions involving one or more applications or code compo- 
nents. An applications server 260 processes requests from 
clients and assembles one or more code components for 
delivery to the client based on the request type. For ex- 
ample, an intranet client 220 may request a report reflect- 
ing interest rate changes over a period of the previous two 
months. The applications server 260 may receive the re- 
quest, activate a reports engine (not shown), transmit the 
report parameters to the reports engine, and transmit the 
resulting report to the requesting intranet client 220. An 
applications server 260 may likewise receive a request for 
a set of forms relating to a particular financial product. 
The applications server 260 may receive the request, acti- 
vate a forms utility (Figure 1, 165) which compiles the re- 
quired forms, transmit form parameters to a forms utility, 
and transmit a forms packet to the requesting client. 
[0036] An XML applications server 260 may include any hardware 
and/or software suitably configured to convert data and/ 
or programming code such as Java and Visual Basic into 
XML. Applications server 260 may transmit data and/or 
programming code to XML applications server 265 in or- 
der to covert it to XML. The converted data or program- 



ming code may then be transmitted back to applications 
server 260 where it may then be transmitted to a request- 
ing client. 

[0037] Synchronization server 255 may be activated by applica- 
tions server 260 in response to a request by a connecting 
remote client 225. Synchronization server 255 may in- 
clude any hardware and/or software suitably configured to 
compare two or more data sources or executable code 
components in order to determine if changes have been 
made to one source and not one or more others. Further, 
synchronization server 255 may update the one or more 
data sources or executable code components in order to 
keep all related sources and components current. For ex- 
ample, a financial advisor working with a remote client 
225 may add a new client to a locally stored database. 
Further, the financial advisor may have compiled one or 
more forms representative of a purchase of a financial 
product by the new customer. 

[0038] a financial advisor, as used herein, may include any indi- 
vidual, business, entity, government organization, soft- 
ware and/or hardware that provides financial advice to 
private individuals, businesses, entities or government or- 
ganizations and/or presides over the sales of financial 



products and services. A financial advisor may interact 
with customers directly or indirectly through a third party. 

[0039] when the remote client 225 in connected to the FS 205 

through an IS 210, applications server 260 may activate a 
synchronization server 255. The synchronization server 
255 may examine the contents of the remote client's 225 
databases to compare it to a counterpart database which 
is a part of the financial system's backend 200. The syn- 
chronization server 255 would recognize that the records 
relating to the new customer and the data captured by the 
new financial product forms does not exist in the counter- 
part backend 200 databases. The synchronization server 
255 may execute a series of steps to copy the records 
from the remote client 225 databases to the counterpart 
backend 200 databases. 

[0040] Financial services 270 may comprise one or more financial 
services which may be available for any number of finan- 
cial advisors. Financial services 270, for example, may in- 
clude a calculator that may be used to determine a cus- 
tomer's retirement account balance under varying circum- 
stances and at different ages. An applications server 260 
may access one or more financial products 270 in re- 
sponse to a connected client request. In the case of a re- 



mote client 225, a synchronization server 255 may ensure 
that the hard drive of the remote client 255 is equipped 
with the appropriate financial services 270. 
[0041] Suitable financial service applications which may be incor- 
porated into the present invention. For example, a system 
and method that provides for an effective work manage- 
ment tool that efficiently organizes a financial advisor's 
day-to-day operations, work flow, clients and prospects. 
The system may also allow coordinated consultation 
based not only on an individual's demographic informa- 
tion, but also on the individual's relationships to others, 
people and organizations are arranged into client groups 
and prospect groups. For additional information on such a 
system and method, see, for example, U.S. Patent No 
5,819,263, entitled "Incorporating Relationship and Group 
Management", by inventors David A. Brounley and Howard 
A. Hallin, issued on October 6, 1998, incorporated herein 
by reference. 

[0042] a system which includes numerous innovative and coordi- 
nated features such as a user friendly interface; unique 
grouping capabilities; a Virtual Executor; a financial Simu- 
lator; an Earmarker; a Strategizer; a Data Wrapper repre- 
sentative of real world grouping of assets, liabilities, in- 



come, and expenses; and a Proposal Constructor. For ad- 
ditional information on such a system and method, see, 
for example, U.S. Patent No. 6,430,542 entitled "Com- 
puter-Implemented Program For Financial Planning and 
Advice System," by inventor William J. Moran, incorporated 
herein by reference. 

[0043] a system and method which provides for easily configur- 
ing new financial advice applications from various services 
and sub-applications in order to deliver consistent advice 
to consumers, clients, and advisors, regardless of the de- 
livery mechanism utilized. For additional information on 
such a system and method, see, for example, U.S. Patent 
Application Serial No. 09/712,743 entitled "Systems and 
Methods for Creating Financial Advise Applications," by 
inventors Roberta L. Patnode, James Richard Ceppert and 
David Hoyt, incorporated herein by reference. 

[0044] Services database 275, customer database 280 and appli- 
cation database may include any hardware and/or soft- 
ware suitably configured to facilitate storing information 
relating to the various applications of the present inven- 
tion. Services data 275 may include information relating 
to the financial services 270. For example, as bond prices 
fluctuate, they may be updated in the services database 



275 thereby ensuring that any financial service calculation 
or simulation relying on current bond will producer the 
most accurate results. 
[0045] Customer database 280 may comprise information relat- 
ing to current or prospective customers including, for ex- 
ample, the customer's name, date of birth, address, tele- 
phone numbers, family details, health information, in- 
come, investments, accounts and the like. This informa- 
tion may be consumed by financial services 270 to as- 
semble scenarios and projections as well as provide a fi- 
nancial advisor insight into the situation and needs of the 
customer. 

[0046] Application database 285 may comprise any information 
used by any other application and/or component of the 
present invention. Application data 285 may represent 
XML schemas which define how data will be processed 
and presented. It may also contain information defining 
any number of preconfigured reports that may be used by 
a report generator to produce reports. Practitioners will 
appreciate that application data 285 may comprise any 
number of databases, database systems and configura- 
tions. 

[0047] The various system components as illustrated in Figure 2 



and previously discussed are presented for the purpose of 
understanding and are not intended to limit the scope of 
the present invention in anyway. Practitioners will appre- 
ciate that there are any number of known system archi- 
tectures, application components and networks that could 
be combined to deliver the functionality of the present in- 
vention. For example, the various servers of the FS 205 as 
illustrated may reside as software and/or hardware com- 
ponents within a single computing device or may be dis- 
tributed in one or more hardware and/or software sys- 
tems. Further, in another embodiment, an IS 210 may not 
be included and all connections to the components of the 
FS 205 may be directed and managed through any other 
means known in the art. 
[0048] The various system components discussed herein may in- 
clude one or more of the following: a server or other com- 
puting systems including a processor for processing digi- 
tal data; a memory coupled to said processor for storing 
digital data; an input digitizer coupled to the processor 
for inputting digital data; an application program stored in 
said memory and accessible by said processor for direct- 
ing processing of digital data by said processor; a display 
device coupled to the processor and memory for display- 



ing information derived from digital data processed by 
said processor; and a plurality of databases. Various 
databases used herein may include: user data, debt data, 
income data, provider data; financial institution data; and/ 
or like data useful in the operation of the present inven- 
tion. As those skilled in the art will appreciate, user com- 
puter may include an operating system (e.g., Windows NT, 
95/98/2000, OS2, UNIX, Linux, Solaris, MacOS, etc.) as 
well as various conventional support software and drivers 
typically associated with computers, user computer can be 
in a home or business environment with access to a net- 
work. In an exemplary embodiment, access is through a 
network or the Internet through a commercially-available 
web-browser software package. 
[0049] As used herein, the term "network" shall include any elec- 
tronic communications means which incorporates both 
hardware and software components of such. Communica- 
tion among the parties in accordance with the present in- 
vention may be accomplished through any suitable com- 
munication channels, such as, for example, a telephone 
network, an extranet, an intranet, Internet, point of inter- 
action device (point of sale device, personal digital assis- 
tant, cellular phone, kiosk, etc.), online communications, 



off-line communications, wireless communications, 
transponder communications, local area network (LAN), 
wide area network (WAN), networked or linked devices 
and/or the like. Moreover, although the invention is fre- 
quently described herein as being implemented with TCP/ 
IP communications protocols, the invention may also be 
implemented using IPX, Appletalk, IP-6, NetBIOS, OSI or 
any number of existing or future protocols. If the network 
is in the nature of a public network, such as the Internet, 
it may be advantageous to presume the network to be in- 
secure and open to eavesdroppers. Specific information 
related to the protocols, standards, and application soft- 
ware utilized in connection with the Internet is generally 
known to those skilled in the art and, as such, need not be 
detailed herein. See, for example, DILIP NAIK, "INTERNET 
STANDARDS AND PROTOCOLS" (1998); "JAVA 2 COM- 
PLETE," various authors, (Sybex 1999); DEBORAH RAY AND 
ERIC RAY, "MASTERING HTML 4.0" (1997); and LOSHIN, 
"TCP/IP CLEARLY EXPLAINED" (1997) and DAVID GOURLEY 
AND BRIAN TOTTY, "HTTP, THE DEFINITIVE GUIDE" (2002), 
the contents of which are hereby incorporated by refer- 
ence. 

[0050] The various system components may be independently, 



separately or collectively suitably coupled to the network 
via data links which includes, for example, a connection to 
an Internet Provider (ISP) over the local loop as is typically 
used in connection with standard modem communication, 
cable modem, Dish networks, ISDN, Digital Subscriber 
Line (DSL), or various wireless communication methods. 
See, e.g., GILBERT HELD, "UNDERSTANDING DATA COM- 
MUNICATIONS" (1996), hereby incorporated by reference. 
It is noted that the network may be implemented as other 
types of networks, such as an interactive television (ITV) 
network. Moreover, the system contemplates the use, sale 
or distribution of any goods, services or information over 
any network having similar functionality described herein. 
[0051] Any databases discussed herein may be any type of 

database, such as relational, hierarchical, graphical, ob- 
ject-oriented, and/or other database configurations. 
Common database products that may be used to imple- 
ment the databases include DB2 by IBM (White Plains, NY), 
various database products available from Oracle Corpora- 
tion (Redwood Shores, CA), Microsoft Access or Microsoft 
SQL Server by Microsoft Corporation (Redmond, Washing- 
ton), or any other suitable database product. Moreover, 
the databases may be organized in any suitable manner, 



for example, as data tables or lookup tables. Each record 
may be a single file, a series of files, a linked series of 
data fields or any other data structure. Association of cer- 
tain data may be accomplished through any desired data 
association technique such as those known or practiced in 
the art. For example, the association may be accom- 
plished either manually or automatically. Automatic asso- 
ciation techniques may include, for example, a database 
search, a database merge, GREP, AGREP, SQL, and/or the 
like. The association step may be accomplished by a 
database merge function, for example, using a "key field" 
in pre-selected databases or data sectors. 
[0052] M 0re particularly, a "key field" partitions the database ac- 
cording to the high-level class of objects defined by the 
key field. For example, certain types of data may be des- 
ignated as a key field in a plurality of related data tables 
and the data tables may then be linked on the basis of the 
type of data in the key field. In this regard, the data corre- 
sponding to the key field in each of the linked data tables 
is preferably the same or of the same type. However, data 
tables having similar, though not identical, data in the key 
fields may also be linked by using AGREP, for example. In 
accordance with one aspect of the present invention, any 



suitable data storage technique may be utilized to store 
data without a standard format. Data sets may be stored 
using any suitable technique, including, for example, 
storing individual files using an ISO/IEC 7816-4 file struc- 
ture; implementing a domain whereby a dedicated file is 
selected that exposes one or more elementary files con- 
taining one or more data sets; using data sets stored in 
individual files using a hierarchical filing system; data sets 
stored as records in a single file (including compression, 
SQL accessible, hashed via one or more keys, numeric, al- 
phabetical by first tuple, etc.); block of binary (BLOB); 
stored as ungrouped data elements encoded using ISO/ 
IEC 7816-6 data elements; stored as ungrouped data ele- 
ments encoded using ISO/IEC Abstract Syntax Notation 
(ASN.l) as in ISO/IEC 8824 and 8825; and/or other pro- 
prietary techniques that may include fractal compression 
methods, image compression methods, etc. 
[0053] | n one exemplary embodiment, the ability to store a wide 
variety of information in different formats is facilitated by 
storing the information as a Block of Binary (BLOB). Thus, 
any binary information can be stored in a storage space 
associated with a data set. As discussed above, the binary 
information may be stored on the financial transaction in- 



strument or external to but affiliated with the financial 
transaction instrument. The BLOB method may store data 
sets as ungrouped data elements formatted as a block of 
binary via a fixed memory offset using either fixed stor- 
age allocation, circular queue techniques, or best prac- 
tices with respect to memory management (e.g., paged 
memory, least recently used, etc.). By using BLOB meth- 
ods, the ability to store various data sets that have differ- 
ent formats facilitates the storage of data associated with 
the financial transaction instrument by multiple and unre- 
lated owners of the data sets. For example, a first data set 
which may be stored may be provided by a first issuer, a 
second data set which may be stored may be provided by 
an unrelated second issuer, and yet a third data set which 
may be stored, may be provided by an third issuer unre- 
lated to the first and second issuer. Each of these three 
exemplary data sets may contain different information 
that is stored using different data storage formats and/or 
techniques. Further, each data set may contain subsets of 
data which also may be distinct from other subsets. 
[0054] As stated above, in various embodiments of the present 
invention, the data can be stored without regard to a 
common format. However, in one exemplary embodiment 



of the present invention, the data set (e.g., BLOB) may be 
annotated in a standard manner when provided for ma- 
nipulating the data onto the financial transaction instru- 
ment. The annotation may comprise a short header, 
trailer, or other appropriate indicator related to each data 
set that is configured to convey information useful in 
managing the various data sets. For example, the annota- 
tion may be called a "condition header", "header", "trailer", 
or "status", herein, and may comprise an indication of the 
status of the data set or may include an identifier corre- 
lated to a specific issuer or owner of the data. In one ex- 
ample, the first three bytes of each data set BLOB may be 
configured or configurable to indicate the status of that 
particular data set; e.g., LOADED, INITIALIZED, READY, 
BLOCKED, REMOVABLE, or DELETED. Subsequent bytes of 
data may be used to indicate for example, the identity of 
the issuer, user, transaction/membership account identi- 
fier or the like. Each of these condition annotations are 
further discussed herein. 
[0055] The data set annotation may also be used for other types 
of status information as well as various other purposes. 
For example, the data set annotation may include security 
information establishing access levels. The access levels 



may, for example, be configured to permit only certain in- 
dividuals, levels of employees, companies, or other enti- 
ties to access data sets, or to permit access to specific 
data sets based on the transaction, provider, issuer, user 
or the like. Furthermore, the security information may re- 
strict/permit only certain actions such as accessing, mod- 
ifying, and/or deleting data sets. In one example, the data 
set annotation indicates that only the data set owner or 
the user are permitted to delete a data set, various identi- 
fied providers are permitted to access the data set for 
reading, and others are altogether excluded from access- 
ing the data set. However, other access restriction param- 
eters may also be used allowing various entities to access 
a data set with various permission levels as appropriate. 
[0056] The data, including the header or trailer, may be received 
by a stand alone interaction device configured to add, 
delete, modify, or augment the data in accordance with 
the header or trailer. As such, in one embodiment, the 
header or trailer is not stored on the transaction device 
along with the associated issuer-owned data but instead 
the appropriate action may be taken by providing to the 
transaction instrument user at the stand alone device, the 
appropriate option for the action to be taken. The present 



invention may contemplate a data storage arrangement 
wherein the header or trailer, or header or trailer history, 
of the data is stored on the transaction instrument in rela- 
tion to the appropriate data. 
[0057] The computers discussed herein may provide a suitable 
website or other Internet-based graphical user interface 
which is accessible by users, hosts or operators of the 
system. In one embodiment, the Microsoft Internet Infor- 
mation Server (IIS), Microsoft Transaction Server (MTS), 
and Microsoft SQL Server, are used in conjunction with the 
Microsoft operating system, Microsoft NT web server soft- 
ware, a Microsoft SQL Server database system, and a Mi- 
crosoft Commerce Server. Additionally, components such 
as Access or Microsoft SQL Server, Oracle, Sybase, In- 
formix MySQL, InterBase, etc., may be used to provide an 
Active Data Object (ADO) compliant database manage- 
ment system. 

[0058] Any of the communications, inputs, storage, databases or 
displays discussed herein may be facilitated through a 
website having web pages. The term "web page" as it is 
used herein is not meant to limit the type of documents 
and applications that might be used to interact with the 
user. For example, a typical website might include, in ad- 



dition to standard HTML documents, various forms, Java 
applets, JavaScript, active server pages (ASP), common 
gateway interface scripts (CGI), extensible markup lan- 
guage (XML), dynamic HTML, cascading style sheets (CSS), 
helper applications, plug-ins, and the like. A server may 
include a web service which receives a request from a web 
server, the request including a URL 
(http://yahoo.com/stockquotes/ge) and an IP address 
(123.56.789). The web server retrieves the appropriate 
web pages and sends the data or applications for the web 
pages to the IP address. Web services are applications 
which are capable of interacting with other applications 
over a communications means, such as the Internet. Web 
services are typically based on standards or protocols 
such as XML, SOAP, WSDL and UDDI. Web services meth- 
ods are well known in the art, and are covered in many 
standard texts. See, e.g., ALEX NCHIEM, "IT WEB SERVICES: 
A ROADMAP FOR THE ENTERPRISE" (2003), hereby incor- 
porated herein by reference. 
[0059] The present invention may be described herein in terms of 
functional block components, screen shots, optional se- 
lections and various processing steps. It should be appre- 
ciated that such functional blocks may be realized by any 



number of hardware and/or software components config- 
ured to perform the specified functions. For example, the 
present invention may employ various integrated circuit 
components, e.g., memory elements, processing ele- 
ments, logic elements, look-up tables, and the like, which 
may carry out a variety of functions under the control of 
one or more microprocessors or other control devices. 
Similarly, the software elements of the present invention 
may be implemented with any programming or scripting 
language such as C, C++, Java, COBOL, assembler, PERL, 
Visual Basic, SQL Stored Procedures, extensible markup 
language (XML), with the various algorithms being imple- 
mented with any combination of data structures, objects, 
processes, routines or other programming elements. Fur- 
ther, it should be noted that the present invention may 
employ any number of conventional techniques for data 
transmission, signaling, data processing, network control, 
and the like. Still further, the invention could be used to 
detect or prevent security issues with a client-side script- 
ing language, such as JavaScript, VBScript or the like. For a 
basic introduction of cryptography and network security, 
the following may be helpful references: (1) "Applied 
Cryptography: Protocols, Algorithms, And Source Code In 



C," by Bruce Schneier, published by John Wiley & Sons 
(second edition, 1996); (2) "Java Cryptography," by 
Jonathan Knudson, published by O'Reilly & Associates 
(1998); (3) "Cryptography & Network Security: Principles & 
Practice," by William Stalling, published by Prentice Hall; 
all of which are hereby incorporated by reference. 
[0060] Each financial advisor may be equipped with a computing 
device in order to interact with the system and facilitate 
online financial advise and financial product sales. The fi- 
nancial advisor may have a computing unit in the form of 
a personal computer, although other types of computing 
units may be used including laptops, notebooks, tablet 
PCs, hand held computers, set-top boxes, cellular tele- 
phones, touch-tone telephones and the like. The financial 
advisor has a computing unit implemented in the form of 
a tablet PC, although other implementations are contem- 
plated by the invention. Financial services provider has a 
computing center shown as a number of servers. However, 
financial service provider's computing center may be im- 
plemented in other forms, such as a mini-computer, a PC 
server, a network of computers located in the same of dif- 
ferent geographic locations, or the like. Moreover, the 
system contemplates the use, sale or distribution of any 



services or information over any network having similar 
functionality described herein. 

[0061] These computer program instructions may also be stored 
in a computer-readable memory that can direct a com- 
puter or other programmable data processing apparatus 
to function in a particular manner, such that the instruc- 
tions stored in the computer-readable memory produce 
an article of manufacture including instruction means 
which implement the function specified in the flowchart 
block or blocks. The computer program instructions may 
also be loaded onto a computer or other programmable 
data processing apparatus to cause a series of operational 
steps to be performed on the computer or other pro- 
grammable apparatus to produce a computer-imple- 
mented process such that the instructions which execute 
on the computer or other programmable apparatus pro- 
vide steps for implementing the functions specified in the 
flowchart block or blocks. 

[0062] Accordingly, functional blocks of the block diagrams and 
flowchart illustrations support combinations of means for 
performing the specified functions, combinations of steps 
for performing the specified functions, and program in- 
struction means for performing the specified functions. It 



will also be understood that each functional block of the 
block diagrams and flowchart illustrations, and combina- 
tions of functional blocks in the block diagrams and 
flowchart illustrations, can be implemented by either spe- 
cial purpose hardware-based computer systems which 
perform the specified functions or steps, or suitable com- 
binations of special purpose hardware and computer in- 
structions. 

[0063] Referring now to Figures 3-4, the process flows as illus- 
trated are merely exemplary embodiments of the inven- 
tion and are not intended to limit the scope of the inven- 
tion as described above. For example, the steps recited in 
any of the method or process descriptions may be exe- 
cuted in any order and are not limited to the order pre- 
sented. It will be appreciated that the following descrip- 
tion makes appropriate references not only to the steps il- 
lustrated in Figures 3-4, but also to the various system 
components as described above with reference to Figures 
1-2. Further, illustrations of the process flows and the de- 
scriptions thereof may make reference to user interface 
windows, webpages, websites, web forms, prompts, etc. 
Practitioners will appreciate that the illustrated steps de- 
scribed below may exist in any number of configurations 



including the use of webpages, web forms, windows, 
popup windows, prompts and the like. It should be further 
appreciated that the multiple steps as illustrated and de- 
scribed may be combined onto single webpages or user 
interface windows but have been expanded for the sake of 
simplicity. In other cases, steps illustrated and described 
as single process steps may be broken down into multiple 
webpages or user interface windows but have been com- 
bined for simplicity. 

[0064] Figure 3 is a flow chart illustrating an exemplary method 
for compiling and completing electronic forms in a remote 
environment. While directed toward managing electronic 
forms in a remote environment, practitioners will appreci- 
ate that a very similar process may be applied to a con- 
nected client. Because financial advisors often visit cus- 
tomers at their homes or places of business, there is not 
always a reliable connection source readily available. While 
a connection to an IS 210 may be possible through a tele- 
phone line or wireless internet connection at a customer 
site, this may not always be the case. Further, such con- 
nections are often slow and unreliable. 

[0065] a financial advisor equipped with a portable computing 
unit, such as a tablet PC, may activate a forms manager 



(step 300). Forms manager (step 300) may include a 
stand-alone software application with its own user inter- 
face or any number of code components to generate 
HTML pages which may be viewed through a browser ap- 
plication. Because the forms manager may contain data 
that is personal and private to customers, the financial 
advisor may be prompted to enter credentials (step 302). 
Credentials may include a user ID, password, pass code, 
or a combination thereof. After entering and submitting 
credentials, a forms manager may authenticate the cre- 
dentials (step 304) by querying a local security database. 
A local security database may comprise a replicated por- 
tion of the authentication database 250 of the FS 205. If 
this is the case, then the users' credentials may be the 
same credentials they would enter when connecting to an 
FS 205. 

[0066] if credentials are not authenticated (step 306), then the fi- 
nancial advisors may again be prompted to enter their au- 
thentication credentials (step 302). However if the creden- 
tials are authenticated, then the financial advisor may be 
prompted to select an action (step 308). Actions may in- 
clude reviewing previously completed forms, synchroniz- 
ing the remote client 225 with an FS 205, or creating 



forms for completion. For the purpose of this illustration, 
only the later will be discussed. The synchronization pro- 
cess will be discussed in greater detail in relation to Fig- 
ure 4. 

[0067] a financial advisor may be prompted to select a customer 
(step 310) for whom the forms will be created. A list of 
current customers may be queried from a local database 
that was replicated from a customer database 280. In one 
embodiment, a financial advisor may enter the name or 
partial name of the customer into a text field in order to 
initiate a search for customers matching the entered name 
or partial name. If the customer does not exist in the 
database and is a new customer (step 312), then the fi- 
nancial advisor may be presented a form and prompted to 
enter customer information (step 314). Customer infor- 
mation may include, for example, customer's name, ad- 
dress, telephone number, email address, birth date, social 
security number and the like. A financial advisor may en- 
ter customer information (step 314) on behalf of the cus- 
tomer (i.e. an interview process), or may ask the customer 
to enter their own information into a pen based tablet PC 
or notebook computer. 

[0068] Following selection of an existing customer (step 310) or 



entering information to create a new customer (step 314), 
a financial advisor may be prompted to select a financial 
service (step 316). Financial services may comprise any 
number of individual services that a financial services or- 
ganization may offer to private individuals and/or busi- 
nesses. For example, a financial services organization may 
offer services for retirement accounts, investment ac- 
counts, lines of credit, banking, insurance, and the like. 
Based on a selection of a financial service (step 316), 
forms manager may query a local database to identify the 
forms that will be required to complete the transaction for 
the selected service. Based on this information, a set of 
forms may be compiled (step 318) and presented in a 
predefined order. On presentation of a form (step 320) 
from the form set, a financial advisor may begin to enter 
customer information into form fields (step 322) on behalf 
of the customer (i.e. an interview process), or may ask the 
customer to enter their own information into a pen based 
tablet PC or notebook computer. 
[0069] Following the completion of a form (step 322), a customer 
may be prompted to review the form for accuracy and sign 
the form as necessary (step 324). One or more signatures 
may be required on a form according to law or company 



policy. In order to obtain a true legal signature, a cus- 
tomer may be directed to sign using a pen based tablet PC 
or any other computing device equipped to enable free 
form text entry or the entry of any type of code to substi- 
tute for a signature. Practitioners will appreciate that such 
devices are commercially available and known in the art. A 
signature may be stored as a bitmap image while other 
data entered into a form may be converted to text. To fa- 
cilitate conversion of free-hand text entry into ASCII text 
that may be electronically processed and stored in one or 
mare files or databases, the present invention may employ 
optical character recognition (OCR) software. Such soft- 
ware is commercially available and increasingly reliable. 
For example, Microsoft has included a class file, Mi- 
crosoft. ink, to it's Visual Studio. Net™ development suite to 
enable developers to include character recognition capa- 
bilities within their software applications. Microsoft. ink 
provides character recognition logic which can be very ef- 
fective in recognizing different print styles. 
[0070] Following the entry of a signature into a form (step 324), 
the forms manager may convert the free-hand text into 
ASCII characters that may be validated to check for 
spelling errors and to ensure that the format of the text is 



appropriate for each form field (step 326). For example, a 
forms manager may convert a birth date field to ASCII text 
and determine that a birth date of 04/19/1848 has either 
been entered into the form incorrectly, or converted to 
ASCII text incorrectly. 
[0071] |f a field cannot be validated for any reason (step 328), 
then a financial advisor and/or customer may be alerted 
and presented an opportunity to correct or re-enter the 
text into the form field (step 332). Once again, the form 
fields may be validated (step 326) to ensure accuracy. 
When all form fields have been validated, (step 328) then 
the form data may be stored within a local database (step 
330) and the forms manager may verify whether or not all 
desired forms for the selected financial service have been 
completed. If all forms are not complete (step 334), then a 
financial advisor and/or customer may be presented with 
the next form in the form set (step 320). If all required 
forms have been completed (step 334), then a financial 
advisor may connect the remote client to an Al (step 336). 
The step of connecting to an Al (step 336) may be per- 
formed at any time following an appointment with a cus- 
tomer. For example, a financial advisor may routinely 
communicate with an Al (336) at the end of the work day 



when she has returned to her hotel room. 
[0072] when the remote client 225 has established a connection 
to an IS 210 and has entered appropriate credentials to be 
authenticated, then intranet server 235 may send a re- 
quest to an applications server 260. Applications server 
260 may initiate a synchronization server 255 that may 
begin the process of uploading data from the remote 
client's 225 local database and synchronizing the data 
(step 338) with the counterpart one or more databases in 
the backend 200. When synchronization is complete, the 
remote client 225 may disconnect from the IS 210. The 
synchronization process will be presented in greater detail 
below. 

[0073] Figure 4 is a flow chart illustrating an exemplary method 
for synchronizing executable code components and data 
between a remote user computing device and the main 
system components of the financial institution. The syn- 
chronization process may be performed at any interval as 
determined by a financial services organization and/or fi- 
nancial advisor. It may be advantageous to synchronize a 
remote client 225 local database with the one or more 
backend 200 databases soon after a sale or modification 
of financial services. Synchronization may occur in batch 



format, real-time or any other interval. 

[0074] when a connection is established between a remote client 
225 and an IS 210 (step 400), a financial advisor may be 
prompted to enter intranet credentials (step 405) in order 
to ensure that the financial advisor is an authorized user. 
When credentials are entered and submitted at the remote 
client 225, an intranet server may query its user database 
240 to authenticate the credentials (step 410). If the cre- 
dentials are not authenticated (step 415), either through 
error or unauthorized use, the financial advisor may again 
be prompted to enter intranet credentials (step 405). 

[0075] Following a successful authentication (step 415), an in- 
tranet 235 may query a user database 240 for authentica- 
tion server 245 credentials (step 420). Storing authentica- 
tion server credentials in an intranet database 240 may 
eliminate the need for a financial advisor to enter two sets 
of credentials when connecting to synchronize. However, 
in another embodiment, it may be desirable to require a 
connecting financial advisor to enter two sets of creden- 
tials in order to add a second layer of security to the sys- 
tem of the present invention. In either case, the financial 
advisor's credentials may be transmitted to an authentica- 
tion server (step 425). Authentication server 245 may 



query an authentication database 250 to determine if the 
credentials match those stored in the authentication 
database 250. If authentication server credentials are not 
authenticated (step 430), then a financial advisor may be 
prompted to again enter intranet credentials (step 405). 
When authentication server 245 credentials are authenti- 
cated, a synchronization request may be transmitted to an 
application server 260 which may initiate a synchroniza- 
tion server (step 435). 
[0076] a synchronization server 255 may use any number of 

means known in the art to determine if changes have been 
made to code components, form components and 
databases. A synchronization server 255 may calculate a 
hash code value for from components and/or code com- 
ponents residing on a connected remote client (step 440). 
Likewise, a synchronization server 255 may calculate the 
hash code value of corresponding form components and/ 
or code components residing in an FS 205 or backend 
200. The two hash values may be compared to determine 
if they match (step 445). If they do not match, indicating 
that a change has been made to the form and/or code 
components, then a request may be transmitted to an ap- 
plications server (step 465). Applications server 260 may 



upload an install file (step 470) to a remote client 225. 
Following a load of an install file, remote client 225 may 
initiate the install file to install the latest version of the 
forms and/or code components (step 475). 

[0077] Practitioners will appreciate that there are a number of 
means known in the art for comparing two or more form 
or code components in order to determine if changes 
were made to one or more of the form or code compo- 
nents. For example, version information and/or modifica- 
tion date may be extracted from two or more form or 
code components to determine if changes were made. 

[0078] An applications server may send a request to a remote 

client 225 in order to extract data from the remote client's 
225 one or more local databases 290. This data may be 
compared to data in one or more corresponding 
databases in the backend 200 to insure that one or more 
records do not already exist (step 450). If it is determined 
that the data from the remote client's 225 one or more 
databases 290 is different than the data contained in the 
one or more corresponding databases in the backend 200 
(step 455), then logic may be employed to determine the 
nature of the changes. For example, if a customer record 
is found to exist in a remote client's 255 local database 



290 and in a corresponding backend 200 database, then 
determination will need to be made as to which record 
was modified most recently. Applying a set of rules, a 
synchronization server 255 may determine how data in 
the backend database should be modified. Synchroniza- 
tion server 255 may extract data that has been changed 
(step 480) and write the data to the appropriate one or 
more databases (step 485) residing in either a remote 
client 225 or backend 200. 
[0079] |f synchronization server 255 determines that there has 
been no changes of data between one or more of remote 
client's 225 local databases 290 and the corresponding 
one or more backend 200 databases (step 455), then re- 
mote client 255 may disconnect from an intranet server 
(step 460). 

[0080] Benefits, other advantages, and solutions to problems 
have been described above with regard to specific em- 
bodiments. However, the benefits, advantages, solutions 
to problems, and any element(s) that may cause any ben- 
efit, advantage, or solution to occur or become more pro- 
nounced are not to be construed as critical, required, or 
essential features or elements of any or all the claims. As 
used herein, the terms "comprises", "comprising", or any 



other variation thereof, are intended to cover a non- 
exclusive inclusion, such that a process, method, article, 
or apparatus that comprises a list of elements does not 
include only those elements but may include other ele- 
ments not expressly listed or inherent to such process, 
method, article, or apparatus. Further, no element de- 
scribed herein is required for the practice of the invention 
unless expressly described as "essential" or "critical". 
[0081] it should be understood that the detailed description and 
specific examples, indicating exemplary embodiments of 
the present invention, are given for purposes of illustra- 
tion only and not as limitations. Many changes and modi- 
fications within the scope of the instant invention may be 
made without departing from the spirit thereof, and the 
invention includes all such modifications. Corresponding 
structures, materials, acts, and equivalents of all elements 
in the claims below are intended to include any structure, 
material, or acts for performing the functions in combina- 
tion with other claim elements as specifically claimed. The 
scope of the invention should be determined by the ap- 
pended claims and their legal equivalents, rather than by 
the examples given above. 



